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ECHNICAL  COMMJN ICATICN 

Hie  development  efforts  of  diverse  coup lax  Navy  systems  and 

equipments  require  diverse  acquisition-management  structures. 

Consequently,  technical  comnunications  mist  be  geared  to  accom- 

* 

modate  these  diversities.  NAVMAT  P39L1  states:  "technical 
comnunications  probably  form  the  mcs  t  important  requirement  for 
a  successful  system  development  program. "  As  early  as  concept 
formulation  and  contract  definition,  formal  outputs  such  as  GOR's, 
TSOR's,  SCSI's,  PTA's  and  TDP's  are  based  upon  the  dialogue  between 
the  user  and  the  producer. 

Technical  communication,  effectively  keyed  to  acquisition  - 
management  stru  d  uxes  requires  that  the  presentation  of  infor¬ 
mation  have  a  high  degree  of  commonality  at  all  system  levels 
in  order  to  form  hierarchical  subsystem  organizations  for  manage- 
mjnt  use.  Since  system  acquisition  is  time  dependent,  technical 
communication  must  also  be  tied  to  the  development  life  cycle  and 
must  grow  with  the  system.  Additional  need  for  commonality  and 
the  time  dependent  updating  of  information  is  reflected  in  the 
fact  that  many  operating  systems  do  not  experience  finite  phase- 
in  phase-out  increments,  tut  rather  grow  and  chaige  with  changing 
requirements . 

*NAVMAT  P39L1  Navy  Systems  Performance  Effectiveness  Manual 
May  1967,  Headquarters,  Naval  Material  Command 


A  technical  cowmnicaticn  schema  must  also  serve  as  a  reference 
far  ether  system  documentation.  This  not  only  allows  change  to 
be  reflected  throughout  the  organisational  structure  but  also 
allows  the  program  manager  to  be  selective  in  terms  of  his  docu- 
aaatatien  needs*  The  scheme  mist  also  have  a  data  capability 
which  provides  critical  inputs  to  the  system  modeling  effort. 

A  system  analytical  model  relies  on  such  information  to  enable 
calculation  of  reliability  and  maintainability  in  terms  of 
system  needs.  Figure  1  summarizes  the  aforementioned  needs  of 
a  technical  communications  scheme. 

In  order  to  bridge  the  technical  communication  gap  between 
the  any  people  involved  in  a  system  acquisition  program  and  to 
meet  the  constraints  set  forth  above,  the  U.S.  Naval  Applied 
Science  Laboratory  developed  the  Design  Disclosure  concept. 
Formally  the  Design  Disclosure  FamuHation.  (DDF)  is i defined  as  a 
technical  conwunication  system  that  links  Navy  program  managers, 
review  teams  and  contractors  by  means  of  lucid,  comprehensive 
and  tiaely  daslgn  disclosures. 

Four  basic  disclosures  comprise .the  DDF  set,  varieties  of 
which  are  keyed  to  specific  points  in  e  system  life  cycle  and 
to  specific  levels  in  a  system  hierarchy.  They  are  Blocked  Text, 
Detailed  Block  Diagram,  Blocked  Schematic  and  Design  Outline. 
Blocked  Text 

The  HLocked  Text  technique  is  used  during  all  acquisition 
phases  and  at  all  system  and  equipment  levels.  It  combines 
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functional  blocks,  hardware,  and  text  on  ana  diagram.  Tha  blocks 
represent  system  and  equipment  functions  and  tbs  text  within  each 
block  describes  the  function,  its  operation  and  associate  relia¬ 
bility,  maintainability,  logistic  and  human  factors  information. 

With  all  text  presented  within  the  blocks,  there  is  no  loss  of 
orientation  between  descriptive  material  and  physical  and  functional 
relationships.  The  text  material  for  the  hardware  mid  functional 
blocks  will  vary  in  accordance  with  data  requirements  for  the 
different  life  cycle  stages.  During  early  phases  of  a  weapon 
system  development,  for  example,  the  information  echelon  includes 
performance,  reliability,  maintainability ,  logistics  and  human 
factors  goals  for  each  subsystem  block  of  the  alternately  pro¬ 
posed  system  schemes.  During  later  design  states,  at  equipment 
and  lower  levels,  text  includes  predicted  reliability  and  main¬ 
tainability  figures,  calculated  failure  end  repair  rates  and  de¬ 
tailed  design  information.  As  indicated  in  Figure  2,  solid  lines 
enclose  the  functions  and  suhfunctione  while  a  broken  line  repre¬ 
sents  hardware  boundary.  This  technique  is  useful  in  disclosing 
the  ways  subfunctions  cut  across  hardware  boundaries  such  as 
racks  and  cabinets. 

Detailed  Block  Diagram 

In  order  to  overcane  the  extreme  difficulty  in  locating 
circuit  functions  and  components  within  system  hardware,  the 
Detailed  Block  Diagrams  is  prepared  during  the  preliminary  de¬ 
sign  phase  of  the  system  life  cycle.  These  diagrams  show  the  basic 


3 


mechanisation  scheme  and  a re  updated  at  latar  design  stages  as  mors 
detailed  circuit  information  baoomss  available.  The  functional 
scbelcns  severed  by  the  Detailed  Block  Diagram*  range  from  equip¬ 
ment  to  circuit  functions.  Is  indicated  in  Figure  3,  the  use  of 
solid  lines  to  enclose  functional  elements  and  broken  lines  to  en¬ 
close  bar  tears  boundaries  allows  for  precise  definition  and  identi¬ 
fication  of  circuits  and  components.  The  broken  line  consisting  of 
s  long  line  and  a  single  dasr  represents  the  highest  level  of  hard¬ 
ware  for  a  particular  diagram.  A  broken  line  separated  by  two 
dashed  indicates  the  next  lowest  lave?  and  so  on.  The  functional 
levels  consist  of  solid  blocks  within  solid  blocks.  This  tech¬ 
nique  provides  s  program  manager  or  design  reviewer  with  a  vari¬ 
able  focus  allowing  him  scan  the  big  picture  or  to  examine 
any  level  of  detail.  The  lowest  functional  level  on  the  Detailed 
Block  Diagram  is  described  by  standard  symbols  such  as  gates, 
anplifiera,  etc.  In  addition  to  precise  functional  and  hardware 
definition,  the  re  diagrams  show  interc  ennecticn  data,  packaging 
data,  test  points  and  front  panel  markings.  Signal  lines  are 
also  codad  to  separate  primary,  secondary,  feedback  and  reference 
paths. 

For  each  Detailed  Block  Diagram,  a  Blocked  Text  Diagram  is 
drawn  on  a  facing  page  so  that  the  dealgn  representation  and  the 
description  of  its  operation  are  together. 
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Blocked  Schematics 


Blocked  Schematic  diagrams  represent  the  most  detailed  level 
of  disclosure  and  is  prepared  dkiring  the  latter  stages  of  the  de¬ 
sign  cycle.  As  shown  in  Figure  h,  the  difference  between  this 
type  of  schematic  and  conventional  schematics  lies  in  the  way  that 
circuits  are  presented.  Instead  of  symmetric  layout,  each  set  of 
circuit  elements  is  grouped  by  functional  aitity.  Each  functional 
entity  enclosed  in  a  solid  block,  is  located  in  a  functional  stage 
which  is  also  enclosed  in  a  solid  block  which  is  located  in  an 
functional  assembly,  etc.  The  functions  are  located  within  hard¬ 
ware  boundaries  in  the  same  manner  as  Derailed  Block  Diagrams 
whereby  a  line  broken  with  a  single  dash  may  represent  a  rack, 
a  line  with  two  dashes  a  drawer,  three  dashes  a  modulo,  etc. 

In  order  to  relate  various  blocked  Schematics  to  the .r 
higher  order  Detailed  Block  Diagram  identical  codes  are  used. 

A  Blacked  Text  Diagram  is  drawn  for  each  Blocked  Schematic. 
Diagram  with  descriptive  text  in  each  functional  block  replacing 
the  circuit  symbols  on  the  Blocked  Schematic.  See  Figure  5. 

The  text  describes  the  operation  of  each  functional  element  and 
includes  reliability  and  maintAinabilitycalculations  in  terras  cf 
failure  rates  and  restore  times. 

Design  Outlines 

The  most  significant  design  disclosure  is  the  Design  Outline 
which  depicts  system  and  equipment  operation  in  terms  of  inputs. 


functions  and  devices,  end  outputs*  This  diagram  is  used  during  all 
phases  of  the  acquisition  cycle  and  at  all  system  levels. 

figure  6  shows  that  three  basic  symbols  represent  conqplex  in¬ 
formation  and  signal  dependency  chains  in  a  clear  and  concise 
manner.  The  result  is  a  logical  model  of  a  system-equipment  design 
which  serves  as  an  extremely  valuable  tool  for  Navy  review  teams, 
designers  and  analysts  who  are  charged  with  the  responsibility  for 
design  assurance  and  optimization. 

The  outline  body  contains  the  dependency  chai r.t  constructed 
from  three  symbols*  a  triangle  is  used  as  a  proof  marker  to  indicate 
dependence  on  a  previous  event}  a  dot  is  used  to  indicate  a  functional 
element}  and  a  rectangle  is  used  to  indicate  an  action,  or  availability 
of  a  signal  or  data,  resulting  from  the  proper  operation  of  the  pre¬ 
ceding  functional  elements. 

Thus,  in  Figure  6,  the  availability  of  output  event  Vi  depends 
upon  the  proper  operation  of  element  S  and  the  availability  of  an 
event  at  R.  Similarly,  the  availability  of  output  event  V2  depends 
upon  tte  proper  operation  of  element  T  and  the  availability  of  the 
event  at  R.  R,  in  turn,  is  an  ’and"  circuit,  because  it  depends  on 
the  availabilities  at  X  and  Y  and  the  proper  operation  of  element  Z. 

The  input  block  diagrams  of  Figure  6  illustrate  that  this  simple 
method  of  representation  is  applicable  to  both  electronic  and 
mechanical  devices.  The  situation  depicted  could  be  a  speaker 
system,  where  a  degraded  operation  would  occur  with  a  failure  of 
either  speaker  (S  or  T),  or  it  could  be  a  gasoline  engine,  where  a 
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degraded  operation,  or  missing  engine,  could  occur  with  a  failure 
of  either  cylinder  (again,  S  or  T).  Without  resort  to  conplicated 
mathematical  formulas,  the  use  of  these  three  basic  symbols  to 
logically  depict  design  dependencies  may  be  extrapolated  to  imich 
more  coz^jlsx  situations,  such  as  typically  found  in  sonar  beam- 
forming  functions,  involving  alternate  signal-path  switching  and 
multiple  channel  flows  and  beam  elements. 

In  support  of  the  Design  Outline  body  which  depicts  the 
logical  design  model,  there  is  a  procedure  column  on  the  left,  a 
data  heading  rear  across  the  top,  and  referenced  performance  speci¬ 
fications  (usually  in  the  right-hand  coluirr).  Figure  7  depicts  a 
conplete  Design  Outline  structure.  The  logical  model  integrated 
with  procedures,  data  headings,  and  specifications  in  a  single 
format  adds  many  dimensions  to  design  clarity  and  understanding. 
For  example,  during  early  system  level  design  the  procedures  con¬ 
tain  the  conditions  for  evant  availabilities  in  the  form  of 
missions,  operational  modes  and  subsystem  submodes;  the  headings 
contain  reliability,  maintainability,  and  performance  goals  for 
each  of  the  system  and  subsystem  functions;  and  the  specifi¬ 
cations  contain  either  system  performance  characteristics  or 
operator  task  requirements  specifically  keyed  to  respective  event 
headings.  Similsrily,  during  detailed  equipment  design,  the  pro¬ 
cedures  could  contain  technician  tasks,  with  the  headings  giving 
calculated  repair  and  failure  rate  data,  and  the  specifications 
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captaining  waveform  and  signal  characteristics.  It  is  particularly 
noteworthy  that  the  Design  Outline  precisely  shows  the  involvement 
of  operator  and  technician  functions  in  the  evolving  design. 

DDF,  DATA  MANAGEMENT  AND  EFFECTIVENESS 
The  essence  of  an  effective  system  development  program  lies 
In  better  understanding  of  the  crosscurrents  between  three  funda¬ 
mental  functional  areas  of  effectiveness.  They  are  design  techno¬ 
logy,  data  Management,  and  analytic  techniques.  DDF  serves  as  a 
mechanism  which  interrelates  these  areas  and  thus  provides  a  tool 
for  improving  design  decisions.  The  previous  descriptions  of  the 
four  basic  formats  showed  that  the  functional  and  hardware  entities 
are  specifically  related  to  design,  performance,  reliability,  main¬ 
tainability,  human  engineering  and  logistics  information  and  data. 
The  development  of  disciplined  analytic  techniques  are  based  upon 
the  information  presented  on  design  outlines.  As  a  decision 
making  tool  for  program  managers,  review  teams  and  designers,  DDF 
complements  other  management  schemes  which  include  the  3M  program 
and  others: 

Management  Control 

The  following  list  includes  those  who  utilize  DDF  for  infor¬ 
mation  and  data  to  enable  decision  making  and  performance  of  ana¬ 
lytic  techniques  Airing  system  development. 

.  Program  Managers 
.  Prime  System  Designers 
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.  Sub-System  Designers 
.  Support  System  Designers 
,  Systems  Analysts 

.  Reliability,  Maintainability  and  Human  Engineering  Groups 
.  Work  Study  Analysts 
.  Design  Review  Teams 
.  Value  Engineering  Groups 
.  Technical  Manual  writers 
.  Personnel  Training  Groups 
.  Logistics  Planners 
.  Secondary  Procurement  Groups 

The  techniques  used  in  a VI  the  formats  allow  these  people  to  direct 
and  oversee  the  system  design.  All  too  often,  in  complex  develop¬ 
ments,  managers  follow  rather  than  lead  the  design  at  significant 
milestones.  As  described  in  Figure  8  management  control  is  effected 
in  the  areas  of  design,  support  documentation,  coordination  and  com¬ 
puter  usage  by  using  DDF. 

Management  cono.ol  within  the  design  is  possible  because  of 
greatly  inproved  technical  interface  control  down  to  the  lowest 
part  level.  Precise  definition  of  boundaries  and  locations,  such 
as  components  within  circuits,  circuits  within  assemblies,  assemb¬ 
lies  within  units,  etc,,  enable  any  design  change  covering  the  spec¬ 
trum  from  overall  system  design  approaches  to  circuit  field  changes, 
to  be  correctly  made,  reviewed,  and  then  measured  for  impact  on  the 
system. 
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Management  control  of  other  supporting  documentation  is 
possible  by  simple  coded  references  to  the  design  disclosures 


At  this  point  it  should  be  emphasized  that  the  DDF  is  not  a 
substitute  for  other  important  system  support  documentation, 
such  as  detailed  engineering  drawings,  ship's  installation 
drawings,  interface  or  configuration  control  documents,  pro¬ 
duction  drawings,  and  technical  manuals,  DIF  is  a  central  con¬ 
trol  which  enable  management  to  recognize  and  act  on  deficiencies 
and  omissions  and  evaluate  theei  in  a  system  context.  There  is 
a  similar  relation  between  the  DDF  and  supporting  material  normally 
required  in  a  design  disclosure  package  from  contractors,  such  as 
costs,  scheduling,  PERT,  R/M  predictions,  work  study,  etc. 

Management  control  in  terms  of  coordination  with  other 
government  and  industry  organizations  can  be  started  early- 
enough  in  design  to  avoid  later  time  and  cost  penalties.  For 
example,  the  complete  definition  of  input  and  output  characteristics 
at  equipment  level  terminal  events,  developed  by  the  designers 
themselves,  is  of  extreme  interest  to  the  Navy's  Electronic  Inter¬ 
face  Management  Office  (EIMO).  If  coordinated  early  enough,  this 
office  could  exercise  a  true  birth  to  death  configuration  control 
of  Navy  equipment.  Another  example  is  the  technical  manual  area. 

The  Naval  Ships  Engineering  Center  (NAVSECNORDIV)  of  Norfolk, 
Virginia  is  vitally  aware  of  technical  manual  deficiencies,  a 
large  percentage  of  which  is  due  to  the  lack  of  diagnosis  infor¬ 
mation.  In  preparation  of  techrical  manuals,  the  publication 
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people  coaid  utilize  a  DDF  data  package  for  this  purpose. 

Modern  management  control  of  complex  operations  is  looking 
more  and  more  for  computer  assistance  for  storage,  updating  and 
retrieval  of  data  and  information.  The  DDF  techniques  are 
uniquely  compatible  with  computer  operations. 

System  Modeling  For  Analysis 

The  dependency  chains  of  the  Issign  Outline  represent  logical 
models  of  evolving  designs  and  thus  become  system  models  at  high 
system  levels.  Complex  system  models  described  via  Design  Outline 
can  be  mapped  directly  into  computers.  The  computer  model  equiva¬ 
lent  of  the  DDF  logical  model  can  be  used  to  store  system  designs 
in  network  library  banks  for  later  modification  and  computer 
aided  analysis.  Because  Design  Outlines  are  in  a  form  for  easy 
tranjlation  into  a  computer,  preliminary  studies  indicate  the 
feasibility  of  automatic  scanning  to  input  system  models.  Given 
additional  system  data,  information,  computer  capability  to  handle 
the  time  parameter  and  mathematical  functions  for  reliability 
diatributions,  meaningful  analysis  can  be  performed.  For  example, 
mission  profiles  and  their  relationships  to  alternate  and  degraded 
modal  dependencies,  combined  with  functional  element  failure  rates 
can  yield  print-outs  of  time  dependent  reliability  per  mission 
duration.  Such  mission  oriented  calculations  would  increase  the 
management  evaluation  confidence  level  of  propoeed  system  designs. 
Design  Analysis 

A  general  listing  of  DDF  design  review  and  analytic  uses  is 
given  in  Figure  9.  These  uses  will  meet  development  cycle  require- 
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amts  prescribed  in  DoD  and  Navy  directives,  including  the  ORMV 
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3910  instruction  series  and  DoD  3200  directives.  Therefore, 
maintenance  concepts  and  plana  are  renewed  in  light  of  require¬ 
ments  during  concept  fcrmulat.i  and  definition  stages.  R/M 
equipment  allocations  are  reviewed  during  preliminary  design, 
and  so  on  down  to  detailed  engineering  design  where  R/M 
analyses  for  optimizing  design  are  performed.  Specific  illustra¬ 
tions  of  the  use  of  the  DDF  as  a  design  analysis  tooi  are  given 
in  the  following  paragraphs  for  each  of  three  areas*. 

.  System  level  analyses, 

.  R/M  analyses,  and 
.  Design-support  interface. 

System  level  analyses  are  performed  during  concept  formulation 
and  contract  definition  phases  to  support  technical  decisions.  De¬ 
cisions  at  this  time  are,  perhaps,  the  most  critical  in  designing 
for  coat/effectiveness.  In  addition  to  the  time -dependent  relia¬ 
bility  printouts  of  con$ruters  discussed  above,  the  high-level  de¬ 
sign  outlines  are  useful  for  ether  important  analyses.  Figure  1C 
shows  a  siiqplified  system  design  outline.  The  heading  contains 
ef f ectivene ss  data  summaries.  Specific  performance  characteristics 
or  man  decision  points  are  related  to  the  events  and  mean  time  to 
failure  (MTBF),  mean  active  repair  times  (MTTR)  and  estimated  in¬ 
active  repair  times  (Logistics  Tims)  are  related  to  the  functional 
entitles.  Valid  and  applicable  data  sources  must  be  carefully 
considered  for  the  inclusion  of  the  data.  Documents  such  as 
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MIL-HDBK-U72  and  NAV  SHIPS  93820  contain  techniques  for  prediction 
of  maintainability  and  reliability  indices. 

The  integrated  design  information  contained  in  system  De¬ 
sign  Outlines  allows  for  various  types  of  analysis.  Cne  is 
analysis  of  the  man /machine  interface.  The  performance  description 
of  an  event  may  be  a  complex  analog  display  which  would  require 
interface  with  a  well  trained  operator.  The  program  manager  may 
wish  to  relieve  the  operator  of  decision-making  responsibility  by 
replacing  the  display  with  a  go,  no-go,  light,  or  two  displays 
which  would  require  two  less  skilled  operators.  Another  type  of 
analysis  is  the  machine/machine  interface.  The  performance 
description  of  an  event  may  cover  the  interface  with  a  data  pro¬ 
cessor.  For  example,  event  descriptions  may  indicate  that  range, 
bearing,  heading  and  speed  information  are  all  available  at  this 
point  for  processor  mating.  Excessive  conversion  requirer.ents 
or  the  inability  of  a  central  processor  to  receive  the  digital 
data  format  required  by  this  design  allows  the  program  manager 
to  make  changes  which  will  meet  the  demands  of  the  interface. 

The  accurate  display  of  each  functional  element  (with  re¬ 
spect  to  individual  as  well  as  all  modes)  and  the  inclusion  of 
the  data  heading  allows  sensitivity  analyses  to  be  performed. 
Reliability  and  maintainability  analyses  are  performed  during  the 
design  phases  of  an  equipment  or  system  life  cycle.  The  data 
base  developed  for  use  with  the  Design  Outline  during  the  da- 
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tailed  design  phases  is  shown  in  Figure  11.  Cost  data  is  given 
in  the  supporting  material  and  is  code-referenced  to  the  Design 
Outlines. 

The  djqpact  of  DDF  as  an  R/M  analytic  tool  is  demonstrated  by 
synthesis  of  repair  and  failure  time  distributions  from  the  design. 
Analyses  from  the  synthesized  distributions  serve  as  the  foundation 
for  improvement  in  maintainability  predictions,  assurance  and  over¬ 
all  design.  The  payoffs  include:  better  R/M  design  assurance 
through  meaningful  requirenents,  identification  of  R/M  problem 
areas,  and  identification  of  the  most  effective  remedial  actions 
to  be  taken  to  improve  designs. 

The  success  of  a  sophisticated  automatic  test  system  is  de¬ 
pendant  on  the  completeness  and  accuracy  of  the  information  con¬ 
cerning  the  prime  design  to  which  it  is  mated.  The  DDF  has  a 
significant  impact  on  the  design/support  interface  because  it 
represents  the  complete  software  package  of  design  information 
and  requirenents.  Figure  12  summarizes  the  DDF  software  package. 
The  disclosures  are  the  controlling  and  coordinating  mechanisms 
for  designing  and  developing  hardware  to  provide  optimum  machine/ 
machine  and  man/machine  features  in  the  test  system.  Optimum  de¬ 
sign  support  interface  provides  successful  maintenance  without 
interfering  with  operational  performance.  The  controlling  soft¬ 
ware  delineates  the  hardware  and  software  support  needed  to 
assure  the  optimum  design /support  interface. 
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DDF  IMPLEMENTATION 


In  order  to  provide  cognizant  Navy  people  a  reference  for 
inclusion  of  DDF  in  their  development  activities,  a  Proposed 
Design  Disclosure  Standard  nas  been  prepared  and  is  currently 
tindergoing  coordination  and  administrative  action.  For  maximum 
flexibility  to  managers  and  engineers,  this  Proposed  Standard 
is  focused  on  formating  requirerrents  and  guides.  Left  to 
their  discretion,  are  particular  data  requirenents  in  performance, 
reliability,  maintainability  etc.,  and  any  particular  utilization 
in  management  control,  system  modeling  and  design  analysis.  Two 
broad  categories  of  DDF  implemen tati on  are  being  pursued  over  and 
above  the  Proposed  Standard,  one  covers  implementing  documentation 
(Specs.,  Stds.,  guides  etc)  for  specific  technical  areas  of  DDF 
utilization,  and  the  other  covers  specific  development  programs 
which  calls  out  the  use  of  all  or  some  of  the  DDF  formats  by 
contract. 

Implementing  Documentation 

Design  Disclosure  techniques  are  presently  being  incorporated 
into  various  documents.  One  such  document  is  the  Automatic  Test 
System  Interface  specification  initiated  by  NAVSEC  (Code  6l8lD). 

The  specification  requires  prime  system  info  rr .at ion  to  be  pre¬ 
sented  via  Design  Disclosure  so  that  optimum  interface  can  be 
effected  with  automatic  test  systems. 

Negotiation  is  presently  being  made  to  incorporate  the  DDF 
concept  into  an  Integrated  Logistics  Support  guide.  This  guide 
will  be  a  product  of  a  NAVSEC  U8lL  effort  in  Ilh  which  also  in- 
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eludes  development  cl  a  Shipboard  Maintenance  Management  plan.  The 
guide  will  aid  the  System  Acquisition  Manager  in  agreement*  to  pro¬ 
vide  total  Integrated  Logistic  Support  for  ships  systems.  The  use 
of  DDF  will  allow  the  acquisition  manager  to  have  maximum  visi- 
bil4  sy  and  control  of  the  system  development  in  terms  of  design 
and  data  accumulation  to  enhance  total  ILS. 

Negotiation  is  also  being  made  to  include  the  DDF  package 
in  the  development  of  a  DoD  Design  Review  Standard  presently  being 
coordinated  by  NAVSEC  (Code  60^7).  The  benefits  .-■’•alized  by  requiring 
DDF  packages  at  specific  design  review  points  in  tto  system  life 
cycle  have  been  mentioned  earlier  in  this  paper. 

Program  Developments 

In  total,  DDF  techniques  for  design  disclosure  are  in  use  in 
about  ten  going  Navy  programs  encompassing  total  ship  as  well  as 
subsystem  levels,  and  the  development  cycle  phases  of  concept 
formulation  through  design.  A  brief  summary  of  the  major  Navy 
applications  to  date  follows  in  tabular  form  below.  The  overall 
approach  in  these  programs  has  been  to  first  validate,  by  usage, 
selected  portions  of  the  developments  before  employing  acrcss- 
t he -board  implementation. 

System  Modeling  Desigr  Review  Prime /Support 

and  Analysis  and  Analysis  Interface 


Conformal 

Planar 

Array 

Sonar 


Used  by  G/D  &  GE 
on  Transmit  beam 
former  during  con¬ 
cept  formulation 


u6 


System  Modeling 
and  Analysis 


Design  Review 
and  Analysis 


Prime /Support 
Interface 


ICG 


Variable 

Depth 

Sonar 

NIXIE 

Acoustic 

Counter- 

measures 

HA  SWT 


TFX-28 

IFF 


Used  by  G/D  during 
ICS  Contract 
definiti on 


Used  by  Tracor  for 
R/M  design  review 
and  analyses 

Used  by  Aerojet 
for  R/M  analyses 


Contract  under 
negotiation,  to 
be  used  by 
Nortronic*  for 
TEAMS/ASW  tor¬ 
pedo  /Target 
Interface 


Used  by  NASL 
in-house  for 
Micro-electronic/ 
packaging  re-design 
of  transponder 
section 

Of  particular  significance  is  the  application  to  the 
Conformal  Planar  Array  Sonar,  wherein  results  indicated  by  G/D 
of  Rochester  showed  that  using  the  DDF  decreased  design  time 
and  Improved  technical  coranuni cat ions  between  G/D  design 
engineers.  Based  on  these  results,  the  DDF  technique  will  be 
broadened  in  the  program  to  serve  as  a  tool  far  overall  manage¬ 
ment  control. 

As  a  further  indication  of  potential  utilization  of  the 

DDF  concept,  examples  of  benefits  which  would  have  bean  derived 

if  DDF  was  used  for  the  design  review  of  the  AN/SQS-26CX  sonar 

are  described  in  a  paper  delivered  at  SPECCN  3*  by  V.  Iacono 

of  the  U.S.  Naval  Applied  Science  Laboratory.  A  few  examples 

are  summarized  as  follows: 

*  17 
Nava]  Material  Command  Third 

System  Performance  Effectiveness  Conference,  May  17,18,  1967 
Washington,  D.  C. 


(1)  DDF  would  have  Immediately  ah own  what  data  was  missing  at  design 
review  points.  Tims,  effort  and  money  would  have  been  saved  in 
gathering  the  data.  (2)  DDF  would  have  allowed  more  inherent  main¬ 
tainability  by  making  the  designer  aware  of  the  techniques  for  pre¬ 
dicting  down-time  via  design  outlines.  (3)  The  overall  system 
representation  with  the  variable  focus  capability  of  DDF  would  have 
enabled  test  point  selection  on  the  basis  of  system  status;  thus 
avoiding  redundant  selection  of  test  points  based  on  indivictual 
cabinet  design. 

Conclusion 

Extensive  research  shows  that  the  Design  Disclosure  Formulation 
is  the  only  current  means  of  collecting  system  oriented  data  and  in¬ 
formation,  in  functional  logic  form,  prior  to  hard  design.  This  fact 
makes  the  DDF  a  pertinent  Tool  for  concept  formulation  and  contract 
definition  activities.  The  logical  commonality  of  DDF  provides  a 
means  for  analysis  reference  and  integration  of  information  within 
complex  systems  for  management  and  design  review  purposes  over  the 
entire  development  cycle.  Since  it  is  expected  that  specific  re¬ 
quirements  fcr  each  procurement  will  be  generated  as  a  normal  con¬ 
sequence  of  the  contracting  process,  flexibilities  have  been  built 
into  the  structure  of  DDF  to  permit  adaptation  of  the  techniques 
to  a  wide  variety  of  applications. 
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Figure  7.  Design  Outline,  Sample 
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Figure  8.  DDF  for  Management  Control 


Figure  9. 


DOF  for  Overall  Design  Analysis 
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Fig  ure  10.  DDF  for  System  Analysis 
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Complete  Software  Package  For  Test  Systems 
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Figure  11  R/M  Analysis  Data  Base 


Figure  12  I’rime/Sujip-'rt  Interface 


